Query Dialog with choice element instead of Buttons

llandale - Mon Sep 12 12:52:06 EDT 2011
A short list of values lets you use a 'radioBox' element, more likely a 'verticalRadioBox. A long list of values practically requires a 'choice' element. An attr that can multiple values requires a multi-list which gets complicated. A short multi-list lets you define an array of individual 'toggle' buttons, but that's also awkward.

As for the dialog mechanics:

No, the 'query' box has only a list of buttons and won't work well for your large possible selections. You need to build a dialog box.

The simple version is to have your selection element and also some action 'button' or 'apply'. That action reads the option and proceeds to do the work. You could I suppose associate a callback with the Element such that it activates as soon as they select something, but I strongly prefer all the actual actions to be invokable only from a button as it forces the user to initiate action mindfully.

Code is activated on a Dialog with callback routines. The stanard method is to associate a function which each 'button' or 'apply' you put on the dialog. You can also associate a callback with an Element such that the code fires when the user does something on the Element (like select a value).

Lets review the difference between dialog 'show' and 'block'. The standard 'confirm' and 'ack' et tal are 'modal' boxes and are displayed internally with a 'block' command. Your blocked 'close' callbacks should generally just 'release' the dialog. When the dialog is 'release'd (in the OK et tal buttons) code proceeds to the line of code after the 'block'. If you create your own dialog that is 'block'd that's a good place to put the 'destroy' command. You have already noticed the rest of the DOORS interface is locked until you deal with this modal dialog. Realistically modal dialogs are for simple but immediate things like "are you SURE??".

A 'show'n dialog will never continue code after the 'show'; you can pretend there is always a 'halt' after the 'show'. You thus must have callbacks in order to make the dialog functional. The 'close' callbacks should clean things up including the 'destroy' of the dialog. You will notice the rest of the DOORS interface is not locked, you can 'show' a dialog and the user can go back to the module and look around before dealing with the dialog. Realistically shown dialogs are for presenting complicated or for non-immiate options to the user.

The chore you described is, IMO, best suited for a standared 'show'n dialog. Your action button should include some form of "This dialog will bla bla bla, are you sure'" 'confirm'.

• Louie

StephenValliere - Mon Sep 12 13:22:17 EDT 2011
Thanks Louie,

I appreciate the detailed overview, though it may not have been entirely necessary it did give me the solution I was looking for. Using the block command instead of show will get me the result I was looking for.

You and Mathias should consider hitting up IBM for some compensation. You guys are typically more helpful and definitely quicker to respond than support.

Thanks again!
-Steve